The use of computer-implemented databases and application programming interfaces (“APIs”) is now fundamental in the archival and use of various types of information, such as relational databases and program code libraries. Data structures that provide the data definitions for relational databases and APIs are referred to herein generally as “database structures” and include but are not limited to data descriptions of database schemas for relational databases, for example, and APIs, for example, in JAVA archive databases (“JARs”). As a result of their ubiquity, database structures comprise primary elements of a wide array of software packages and are instrumental in many aspects of compiling, cataloging, sorting, and retrieving information and for controlling aspects of program execution. However, the use of upgraded database structures is often limited by problems encountered when upgrading or changing the database structures or software designs. Specifically, a fully functional database system or other application that properly functions under an original database structure often fails to function under an upgraded database structure due to changes within the database structure. Similarly, software or applications that rely upon an original database structure for functional or operational support often fail to function properly under an upgraded database structure due to changes within the design of the database structure. Moreover, when the upgraded data includes a library of byte codes, such as a JAR, incompatibilities in the upgraded JAR can cause operating problems in the preexisting application. Thus, every time an original database structure is upgraded there is a risk that databases or applications which functioned under the original database structure will not function properly under the upgraded database structure.
For instance, if a DB2 database functions properly under a first set of database definitions it may not function at all if the DB2 database is upgraded to utilize an upgraded set of definitions which vary in some respect from the first set of definitions.
Similar problems exist when upgrading JARs, which include a plurality of APIs. Specifically, an application may function properly under a first JAR which utilizes a first set of APIs but not function at all under a second JAR which utilizes a second set of APIs that vary in some respect from the first set, such as by changing class constructors or method signature information including, for example, the number and order of arguments.
Existing methods are known for comparing database structures, including database schemas, JARs, APIs, and other data structures, but these conventional methods lack the ability to specifically identify the important differences between the two database structures. For example, a conventional method may identify that two database schemas are different, but cannot identify how they are different such that a database may be changed to function accordingly. By way of another example, known methods involve completely decompiling two JARs and comparing the two decompiled outputs. However, such comparisons fail to provide useful information about the relevant differences between the two JARs. Thus, known database structure comparison methods are unable to identify the forward and backward compatibility of two database structures in a particular application.
Additionally, known methods lack accurate comparison means and often inaccurately generate a plurality of non-existent incompatibilities based on an inaccurate comparison. For instance, known database structure comparison methods utilize standard symmetrical comparison which compares two database structures character by character or line by line to determine if the two structures are the same. Thus, two database structures may be functionally identical, but if one database includes an extra embedded white space, or any other element that is not dependent on the database structure and that is not relevant to the database structure, conventional comparison methods would identify the two database structures as being different. Similarly, two database structures may be functionally equivalent by containing identical components, but conventional comparison methods would identify the two database structures as being different if the components are positioned at different locations within each database structure.